home *** CD-ROM | disk | FTP | other *** search
/ TPUG - Toronto PET Users Group / TPUG Users Group CD / TPUG Users Group CD.iso / CRS / crs56.d81 / linkfrmt.seq < prev    next >
Text File  |  2009-10-10  |  7KB  |  126 lines
  1. ╨LEASE WAIT WHILE ╔ RELOAD TABS
  2. ╞ROM PRINDLE@NADC.ARPA ╘HU ─EC  7 11:25:28 1989
  3. ╥ETURN-╨ATH: <PRINDLE@NADC.ARPA>
  4. ─ATE: ╘HU, 7 ─EC 89 08:36:55 ┼╙╘
  5. ╞ROM: PRINDLE@NADC.ARPA (╞RANK ╨RINDLE)
  6. ╘O: ACLIU@SKAT.USC.EDU
  7. ╙UBJECT: ╥E:  ╨OWER-├ ╧BJECT FORMAT
  8.  
  9. ╧K, HERE IS A COPY OF MY POSTING ON THIS SUBJECT FROM A YEAR OR SO AGO - HOPE
  10. IT HELPS, ┴LEX....
  11. ----------------------------------------------------------------------
  12. ╚ERE IS, AS ╔ RECALL IT, THE FORMAT OF A ├ ╨OWER (┴╦┴ ╨OWER ├) RELOCATABLE
  13. OBJECT (I.E. A ".O" OR ".OBJ") FILE; OTHERS, PLEASE CORRECT ME IF THIS IS
  14. WRONG, THOUGH ╔ CHECKED IT OUT WITH THE ├ ╨OWER ASSEMBLER (┴╙╙═) SOURCE CODE
  15. AND THE ├ ╨OWER REVERSE ASSEMBLER (╥┴) SOURCE CODE:
  16.  
  17. ╘HERE ARE 5 DISTINCT PARTS TO THE OBJECT FILE; EACH PART BEGINS WITH A 2 BYTE
  18. COUNT IN STANDARD 6502 LOW-BYTE/HI-BYTE FORMAT.  ╘HE 5 PARTS DIRECTLY FOLLOW
  19. EACH OTHER IN THE FOLLOWING ORDER:
  20.  
  21.        1. RELOCATABLE OBJECT CODE
  22.        2. RELOCATION ENTRIES
  23.        3. EXTERNAL DEFINITION ENTRIES
  24.        4. EXTERNAL REFERENCE ENTRIES
  25.        5. UNINITIALIZED DATA BLOCK ENTRIES
  26.  
  27. ╔ WILL DESCRIBE EACH PART IN DETAIL:
  28.  
  29. 1. RELOCATABLE OBJECT CODE:
  30.        ╘HE FIRST 2 BYTES ARE A BYTE COUNT OF THE OBJECT CODE TO FOLLOW.  ╫HAT
  31.        FOLLOWS IS SIMPLY THE GENERATED OBJECT CODE FOR THE CORRESPONDING SOURCE
  32.        CODE FILE.  ╞OR THOSE INSTRUCTIONS AND .BYTE OR .WORD PSEUDO OPS WHICH
  33.        REFERENCE RELOCATABLE ADDRESSES WITHIN A FUNCTION (TYPICALLY FOR LOCAL
  34.        JUMPS), THE VALUE IN THE OPERAND FIELD IS THE OFFSET RELATIVE TO THE
  35.        FIRST WORD OF OBJECT CODE.  ╞OR THOSE INSTRUCTIONS AND .BYTE OR .WORD
  36.        PSEUDO OPS WHICH REFERENCE EXTERNALLY DEFINED ADDRESSES, THE VALUE OF
  37.        THE OPERAND FIELD IS IRRELEVANT AND TYPICALLY FILLED IN BY THE COMPILER
  38.        WITH BYTES WHICH DUPLICATE THE BYTE WHICH IMMEDIATELY PRECEEDS THEM.
  39.        ╘HIS PART ENDS WHEN THE NUMBER OF BYTES OF OBJECT CODE SPECIFIED IN THE
  40.        COUNT HAVE BEEN ENCOUNTERED.
  41.  
  42. 2. RELOCATION ENTRIES:
  43.        ╘HE FIRST 2 BYTES ARE A COUNT OF THE NUMBER OF RELOCATION ENTRIES TO
  44.        FOLLOW.  ┼ACH RELOCATION ENTRY IS EXACTLY 2 BYTES LONG AND CONSISTS OF
  45.        AN OFFSET RELATIVE TO THE FIRST BYTE OF OBJECT CODE.  ╘HIS OFFSET
  46.        ACTUALLY POINTS TO THE BYTE BEFORE A 2-BYTE ADDRESS WHICH IS TO HAVE
  47.        ADDED TO IT THE ABSOLUTE ADDRESS OF THE FIRST WORD OF OBJECT CODE; THAT
  48.        IS, FOR 3-BYTE INSTRUCTIONS, THIS OFFSET POINTS TO THE OP-CODE PRECEED-
  49.        ING AN ADDRESS TO BE RELOCATED; FOR 2-BYTE ADDRESSES WITHOUT AN OP-CODE
  50.        (E.G. .WORD PSEUDO OPS), THE OFFSET POINTS TO THE BYTE BEFORE THE
  51.        ADDRESS TO BE RELOCATED.  1-BYTE ADDRESSES TO BE RELOCATED (E.G. >ADDR
  52.        OR <ADDR) ARE NOT HANDLED BY THIS RELOCATION MECHANISM, BUT RATHER AS
  53.        PSEUDO EXTDEFS/EXTREFS (SEE BELOW).  ╘HIS PART ENDS WHEN THE NUMBER OF
  54.        2-BYTE RELOCATION ENTRIES SPECIFIED IN THE COUNT HAVE BEEN ENCOUNTERED.
  55.  
  56. 3. EXTERNAL DEFINITION ENTRIES
  57.  
  58.        ╘HE FIRST 2 BYTES ARE A COUNT OF THE NUMBER OF EXTERNAL DEFINITION
  59.        ENTRIES TO FOLLOW.  ┼ACH EXTDEF ENTRY IS A VARIABLE NUMBER OF BYTES
  60.        LONG.  ╞IRST APPEARS THE EXTERNALLY DEFINED NAME, TERMINATED WITH A
  61.        ZERO BYTE.  ╬EXT IS A 1-BYTE FLAG; IF THIS FLAG IS 0, THE EXTERNALLY
  62.        DEFINED SYMBOL HAS AN ABSOLUTE VALUE; IF THIS FLAG IS A 1, THE EXTERNAL-
  63.        LY DEFINED SYMBOL HAS A RELOCATABLE VALUE RELATIVE TO THE FIRST BYTE
  64.        OF OBJECT CODE.  ╞INALLY, THE LAST 2 BYTES OF EACH ENTRY ARE THE
  65.        ABSOLUTE VALUE OF THE (ABSOLUTE) SYMBOL, OR THE OFFSET OF THE (RELOC-
  66.        ATABLE) SYMBOL.  ╫HENEVER THE COMPILER MUST REFERENCE ONLY THE LOW OR
  67.        HIGH BYTE ADDRESS OF A LOCAL PIECE OF STATIC DATA (E.G. A STRING
  68.        LITERAL), THAT DATUM IS GIVEN A "PSEUDO" EXTERNAL DEFINITION; THAT IS,
  69.        THE COMPILER MAKES UP A NAME FOR IT CONSISTING OF SEVERAL RANDOMLY
  70.        GENERATED SPECIAL CHARACTERS AND ADDITIONAL IDENTIFIER CHARACTERS,
  71.        THEN TREATS IT AS IF IT WERE AN EXTERNAL DEFINITION.  ╘HIS IS DONE SO
  72.        THAT IT MAY BE REFERENCED BY AN EXTERNAL REFERENCE ENTRY TO FOLLOW.
  73.        ╘HIS PART ENDS WHEN THE NUMBER OF MULTI-BYTE EXTDEF ENTRIES
  74.        SPECIFIED IN THE COUNT HAVE BEEN ENCOUNTERED.
  75.  
  76. 4. EXTERNAL REFERENCE ENTRIES:
  77.        ╘HE FIRST 2 BYTES ARE A COUNT OF THE NUMBER OF EXTERNAL REFERENCE
  78.        ENTRIES TO FOLLOW.  ┼ACH EXTREF ENTRY IS A VARIABLE NUMBER OF BYTES
  79.        LONG.  ╞IRST APPEARS THE EXTERNALLY REFERENCED NAME, TERMINATED WITH
  80.        A ZERO BYTE.  ╬EXT IS A 2-BYTE WORD IN LOW/HI FORMAT; THE LOW 2 BITS
  81.        OF THIS WORD INDICATE IF THIS EXTERNAL REFERENCE IS TO A FULL 2-BYTE
  82.        ADDRESS (FLAG=0), A SINGLE BYTE TO CONTAIN THE HIGH BYTE OF THE ADDRESS
  83.        (FLAG=1), OR A SINGLE BYTE TO CONTAIN THE LOW BYTE OF THE ADDRESS (FLAG=
  84.        2).  ╘HE UPPER 14 BITS OF THIS WORD ARE AN OFFSET INTO THE EXTERNAL
  85.        OBJECT.  ╞INALLY, THE LAST 2 BYTES OF EACH ENTRY ARE THE OFFSET OF THE
  86.        EXTERNAL REFERENCING INSTRUCTION (POINTS 1 BYTE BEFORE THE EXTERNAL
  87.        ADDRESS REFERENCE ITSELF) RELATIVE TO THE FIRST BYTE OF OBJECT CODE.
  88.        ╔N THE CASE OF REFERENCES TO "PSEUDO" EXTERNAL DEFINITIONS, THE
  89.        REFERENCE WILL BE RESOLVED BY THE MATCHING EXTERNAL DEFINITION, AND
  90.        THE FLAG WILL ALWAYS BE EITHER 1 OR 2.  ╘HIS PART ENDS WHEN THE NUMBER
  91.        OF MULTI-BYTE EXTREF ENTRIES SPECIFIED IN THE COUNT HAVE BEEN
  92.        ENCOUNTERED.
  93.  
  94. 5. UNINITIALIZED DATA BLOCK ENTRIES:
  95.        ╘HE FIRST 2 BYTES ARE A COUNT OF THE NUMBER OF DATA BLOCK ENTRIES
  96.        TO FOLLOW.  ┼ACH DATA BLOCK ENTRY IS A VARIABLE NUMBER OF BYTES
  97.        LONG.  ╞IRST APPEARS THE DATA BLOCK NAME, TERMINATED WITH A ZERO
  98.        BYTE.  ╠ASTLY IS A 2-BYTE SIZE, REPRESENTING THE NUMBER OF DATA
  99.        BYTES TO BE RESERVED BY THE LINKER (AND ZEROED BY THE RUN-TIME
  100.        INITIALIZATION CODE) FOR THAT NAMED DATA BLOCK.  ╘HESE ENTRIES ARE
  101.        USED TO REPRESENT UNINITIALIZED STATIC OR EXTERNAL DATA TO PREVENT
  102.        LARGE OBJECT MODULES FILLED WITH NOTHING BUT ZEROS.  ╙INCE THE
  103.        DATA BLOCK NAMES ARE EFFECTIVELY EXTERNALLY DEFINED, DUMMY "PSEUDO"
  104.        EXTDEF NAMES ARE AGAIN CREATED WHEN LOCAL STATIC DATA IS TO BE
  105.        ALLOCATED AS AN UNINITIALIZED DATA BLOCK.  ╘HE PURPOSE OF THESE
  106.        RANDOMLY GENERATED DUMMY NAMES IS TO CLUE THE LINKER THAT THESE ARE
  107.        NOT REAL EXTERNAL DEFINITIONS, AND TO PREVENT EXTERNAL NAME CONFLICT
  108.        WITH IDENTICALLY NAMED LOCAL DATA IN OTHER OBJECT MODULES.  ╘HIS PART
  109.        ENDS WHEN THE NUMBER OF MULTI-BYTE DATA BLOCK ENTRIES SPECIFIED IN THE
  110.        COUNT HAVE BEEN ENCOUNTERED.  ┴T THIS POINT THE OBJECT FILE IS AT
  111.        END-OF-FILE.
  112.  
  113. ╔ HOPE THE ABOVE IS A REASONABLY COMPLETE AND USEFUL DESCRIPTION OF ├ ╨OWER
  114. OBJECT CODE.  ╥EFER ALSO TO THE ╘RANSACTOR (═ARCH 1988) ARTICLE "╘HE LINK
  115. BETWEEN ├ AND ASSEMBLY".  ┴LSO NOTE THAT ┴╙╙═ FAITHFULLY ADHERES TO THE ABOVE
  116. FORMAT SO THAT ┴╙╙═ GENERATED OBJECT FILES MAY DIRECTLY BE LINKED WITH THOSE
  117. GENERATED BY ├ ╨OWER; HOWEVER, ┴╙╙═ USES A DIFFERENT ALGORITHM FOR THE
  118. GENERATION OF PSEUDO EXTDEF NAMES, ATTEMPTING TO MAKE THOSE NAMES MORE
  119. READABLE WITHOUT SACRIFICING THEIR UNIQUENESS.
  120.  
  121. ╙INCERELY,
  122. ╞RANK ╨RINDLE
  123. ╨RINDLE@╬┴─├.ARPA
  124.  
  125.  
  126.